DRAFT — under teacher review.

Scope vs Constraints — What's the Difference?

The Hamilton and Alexandra College · Year 12 · 2026

In C3-1 interviews, students frequently say "we couldn't do X because of budget" and call it out-of-scope — when it is actually a constraint. These two concepts live in different sections of the SRS and serve different purposes.

The one-sentence rule

Concept	One-sentence definition	Where it lives in the SRS
Scope	What the solution will and will not do — the boundaries of the deliverable	SRS scope section; often expressed with MoSCoW
Constraint	A real-world limit that restricts what can be done — budget, law, hardware, time	SRS constraints section; categorised (economic, legal, social, technical, usability)

The key distinction

Scope is about the solution's boundary — you are deciding, with the client, what features are in and out. You have some agency in this decision.

Constraints are facts of the world — limits imposed on the project by external realities. You cannot remove them by negotiating with the client.

Budget, existing hardware, privacy law, school policy, and the six-week timeline are all constraints — they existed before you wrote a single line of requirements.

Whether the app will support multiple languages or only English is a scope decision.

Side-by-side: same project, two tables

The scenario: a school canteen ordering app.

Scope table (MoSCoW)

Priority	Feature	In scope?
Must	Students can place a lunch order by 10 am	Yes
Must	Staff can view and print daily orders	Yes
Should	SMS notification when order is ready	Yes
Could	Loyalty points system	No — out of scope
Won't	Integration with the school's finance system	No — out of scope for this version

The "Won't" and "Could (excluded)" items are out of scope — the team has decided not to include them in this version.

Constraints table

Category	Constraint
Economic	Development must be completed with no additional software licences — free/open-source tools only. Budget for hosting is $0 (school server only).
Legal	Must comply with the Privacy Act 1988 (Cth) — student names and order histories cannot be stored beyond 30 days without consent.
Social	The canteen is staffed by volunteers with low technical confidence — the interface must require no training to operate.
Technical	Must run in any modern web browser; school iPads run iOS 15. No native app — web-based only.
Usability	Must be operable with one hand (to hold a tray) by primary-school users (Year 5+).

The test: budget as constraint, not scope

A very common error:

~~"The loyalty points system is out of scope because we don't have the budget to build it."~~

Budget is a constraint (economic). The loyalty points system may be out of scope — but the reason it is out of scope is a separate matter. Write them separately:

Constraints → "Economic constraint: development resources are limited to the 6-week timeline and free tools; no budget for third-party APIs."
Scope → "Won't: loyalty points system — excluded from this version to keep scope achievable within the economic constraint."

You can cross-reference them like that in your SRS. That is what the 9–10 band looks like.

MoSCoW and constraints work together

MoSCoW is how you communicate scope. Constraints are the reasons some things end up in "Could" or "Won't". A strong SRS makes that link explicit — a "Won't" item that exists because of a legal or economic constraint should say so.

At 7–8 band, students describe scope and constraints separately but don't connect them.

At 9–10, students show that the constraint drove the scope decision: "The loyalty points system is classified as Won't due to the economic constraint — no budget for third-party payment processing or secure token storage within the project timeline."

Why VCAA cares

At 5–6, the rubric requires you to "document the constraints that may impact the development of the proposed solution" and to "describe the scope of the proposed software solution". These are two separate indicators — they must both appear in the SRS, in separate sections, clearly labelled.

Mixing them up (writing constraints under scope, or calling constraints "things we won't do") signals to the examiner that the student does not understand the analysis stage of the problem-solving methodology.